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ABSTRACT 

Innovation  projects  are  "partitioned"  into  smaller  tasks.  Precisely  where  the 
boundaries  between  such  tasks  are  placed  can  affect  project  outcome  and  the 
efficiency  of  task  performance  due  to  associated  changes  in  the  problem-solving 
interdependence  among  tasks. 

I  propose  that  problem-solving  interdependence  among  tasks  can  be  predicted 
in  many  projects,  and  can  then  be  managed  by  strategies  involving  (1)  adjustment  of 
the  boundaries  between  tasks,  and/or  (2)  reduction  of  thebarriers  to  problem-solving 
interaction  across  selected  or  all  task  boundaries. 

The  potential  value  of  studying  and  managing  task  partitioning  is  illustrated  by 
exploring  how  problematic  areas  of  the  innovation  process,  such  as  the  design-build 
and  marketing-R&D  interfaces,  can  be  better  understood  through  that  lens. 


1    I  am  indebted  to  Anne  Caner,  Professor  of  Economics,  Brandeis  University,  to  Dietmar 
Harhoff,  PhD  Candidate  at  the  MIT  Sloan  School  of  Management,  and  to  Stephan  Schrader, 
Assistant  Professor  of  Management,  MIT  Sloan  School  of  Management,  for  their  thoughtful 
critiques  of  this  paper. 


Task  Partitioning: 
An  Innovation  Process  Variable 

1.0:  Introduction 

Innovation  process  researchers  have  studied  how  one  might  organize 
innovation  most  efficiently  and  effectively  from  many  points  of  view.  Interestingly, 
however,  an  almost  vanishingly  small  element  of  this  literature  deals  with  the  proper 
organization  of  innovation  work  with  respect  to  the  requirements  of  problem-solving. 
I  propose  that  this  is  an  important  gap,  because  the  core  function  of  many  innovation 
projects  and  project  tasks  is  precisely  problem-solving  and  the  generation  of  new 
information.  In  this  paper,  therefore,  I  explore  the  link  between  innovation  project 
"task  partitioning"  (how  an  innovation  project  is  divided  into  tasks)  and  the 
efficiency  and  effectiveness  of  innovation  project  work. 

I  first  characterize  task  partitioning  (section  2).  Next,  I  discuss  the  impact  of 
partitioning  on  the  on  innovation  project  efficiency  (section  3)  and  consider  how  the 
partitioning  process  might  be  improved  (section  4).  I  then  illustrate  the  practical 
importance  of  task  partitioning  by  considering  how  problematic  areas  of  the 
innovation  process,  such  as  the  design-build  interface  and  the  marketing-R&D 
interface,  can  be  better  understood  via  the  lens  the  partitioning  variable  provides 
(section  5).  Finally,  I  offer  suggestions  for  further  research  (section  6). 


2.0:  Dividing  An  Innovation  Project  Into  Tasks 

An  innovation  project  of  any  magnitude  is  divided  up  ("partitioned")  into  a 
number  of  tasks  and  subtasks  that  may  then  be  distributed  among  a  number  of 
individuals,  and  perhaps  among  a  number  of  firms.  Task  partitioning  need  not  be 
completed  prior  to  the  start  of  project  work.  Indeed,  as  we  will  see  later,  the 


division  of  project  work  into  tasks  may  appropriately  proceed  as  the  project  itself 
proceeds.  Nonetheless,  if  we  were  able  to  look  at  a  completely  partitioned  project, 
what  we  would  see  is  all  component  tasks  and  task  interfaces  specified,  implicitly  or 
explicitly,  so  that  all  would  fit  and  work  together  to  form  the  total  project  when 
combined.  Such  specifications  say  in  effect:  "This  is  the  nature  of  Task  X.  These 
are  the  inputs  it  will  or  can  receive  from  other  parts  of  the  project;  and  these  are  the 
outputs  it  must  provide  to  specified  points  in  the  project  at  specified  times." 

Note  that  the  partitioning  being  focused  on  involves  the  innovation  work  itself 
rather  than  the  product  or  process  resulting  from  that  work.  For  example  a  new 
product  may  physically  consist  of  components  A  and  B.  But  the  innovation  project 
tasks  leading  to  the  development  of  that  product  may  have  been  partitioned  according 
to  different  boundaries,  and  it  is  the  latter  we  are  concerned  with  here. 

Small  innovation  projects  may  be  partitioned  into  tens  or  hundreds  of 
component  tasks.  Large  projects  may  be  divided  into  thousands  or  even  tens  of 
thousands  of  such  tasks,  woven  into  an  intricate  network  of  interrelationships. 


Figure  1 :  Schematic  of  Simple  Project  Task  Network 


Figure  1  shows  a  simple  project  task  network  in  schematic  form.  Here,  tasks 
(or  groups  of  tasks)  are  shown  as  circles  or  nodes,  and  interconnecting  lines  show 
the  nature  of  task  interdependencies  -  that  is,  show  that  the  outputs  of  some  tasks  are 
required  as  the  inputs  of  others. 

Task  networks  can  be  drawn  at  a  number  of  levels  of  aggregation  depending 
on  one's  purpose.  For  example,  if  one  is  planning  to  manage  the  start-up  of  an 
entire  auto  company,  "develop  car  model  X"  may  well  be  shown  as  a  single  activity 
in  a  complex  task  network.  But  managers  responsible  for  that  project  only  might 
well  devote  an  entire  networic  to  related  tasks  -  perhaps  to  the  level  of  detail  of 
"develop  front  left  door  of  car  model  X".  Then,  those  in  charge  of  door 
development  work  might  in  tum  develop  a  network  consisting  of  tasks  at  the  level  of 
"develop  door  locking  mechanism",  and  so  forth. 

There  are  many  different  ways  to  partition  a  given  project.  Thus,  in  the 
instance  of  the  "develop  car  model  X"  activity  mentioned  above,  project  participants 
might  decide  to  specify  "develop  left  front  door"  as  a  task,  or  they  might  decide  to 
specify  "develop  left  side  of  car"  as  a  task  and  then  specify  subsidiary  tasks  such  as 
"develop  windows",  etc.,  in  a  way  that  never  isolates  development  of  the  door  itself 
as  a  separate  task.  In  many  firms,  certain  task  partitionings  may  be  so  traditional  as 
to  seem  fixed  -  e.g.,  car  firm  Y  may  "always"  have  had  a  door  development  group. 
Nonetheless,  task  partitioning  is  in  fact  a  manageable  innovation  process  variable. 


3.0:  Task  Changes,  Problem-Solving  Interdependence  and  Efficiency 

Project  managers  specify  tasks  and  their  interrelationships  so  that  they  can 
distribute  innovation  effort  across  people  and  organizations,  both  in  parallel  and  in 
series  with  respect  to  time.  It  is  the  assumption  that  task  boundary  (input  and 
output)  specifications  wiU  be  relatively  stable  as  a  project  proceeds  that  allows 


project  participants  to  focus  on  their  own  tasks,  with  some  assurance  that  their 
output  will  properly  mesh  with  the  output  of  others  to  comprise  the  total  intended 
project  output. 

Yet  changes  to  task  specifications  and  interrelationships  are  often  required 
during  the  course  of  a  project  because  planning  errors  were  made,  or  because  new 
information  is  introduced  that  was  not  available  at  that  project's  start.  In  the  instance 
of  innovation  projects,  changes  for  the  latter  reason  are  especially  likely,  because  the 
core  function  of  many  innovation  project  tasks  is  precisely  problem-solving  and  the 
generation  of  new  information. 

Changes  caused  by  a  single  new  information  "event"  may  be  restricted  to  only 
one  task,  or  may  affect  the  task  network  more  widely.  For  example,  suppose  that  a 
task  in  an  auto  development  project  involves  research  directed  towards  developing  a 
very  fuel-efficient  engine.  And  suppose  that  research  reveals  that  the  originally 
planned  approach  to  that  problem  will  not  succeed.  Then,  one  might  devise  a  new 
approach  to  achieving  that  same  goal,  in  which  case  no  other  task  need  be  affected 
by  the  new  information.  Or,  one  might  decide  that  one  will  change  other  tasks  or 
their  interrelationships  to  compensate  for  the  shortfall  and  maintain  overall  project 
performance.  (For  example,  one  might  decide  to  try  to  lower  friction  in  the  drive 
train,  and/or  try  to  decrease  the  weight  of  the  car  to  meet  the  original  goal  for  fuel 
efficiency.)  In  this  latter  case  the  response  of  project  participants  to  the  new 
information  clearly  involves  more  extensive  changes  in  the  established  task  network. 

With  this  example  in  mind,  let  me  defme  the  interdependence  between  any 
two  innovation  project  tasks  with  respect  to  problem-solving  as  the  probability  that 
efforts  to  perform  one  of  the  tasks  to  specification  are  likely  to  spiU  over  and  require 
coordinated  problem-solving  in  the  other.  The  higher  this  probability  in  a  given 
instance,  the  greater  the  problem-solving  interdependence. 

Changes  introduced  to  task  specifications  after  task  work  is  under  way  can  be 
costly  because  they  often  make  what  is  already  done  valueless,  and/or  may  degrade 


the  solution  ultimately  arrived  at,  as  project  participants  strive  to  "save"  work  already 
done  by  making  suboptimal  adaptations  to  change. 

I  propose  that  the  cost  of  such  changes  will  be  less,  other  things  being  equal, 
if  task  boundaries  are  arranged  to  reduce  the  problem-solving  interdependence 
among  project  tasks.  (Note  that  such  partitioning  changes  will  not  necessarily  reduce 
or  increase  -  the  amount  of  problem-solving  required  in  a  given  innovation  project. 
They  simply  affect  how  that  problem-solving  is  distributed  among  tasks.) 

This  proposal  is  not  novel.  In  1964,  Christopher  Alexander,  an  architect, 
proposed  that  the  overall  designs  of  houses  or  communities  could  be  improved  if 
they  were  made  up  of  subsystems  that  could  be  adjusted  relatively  independently. 
Traditional  designs  had  this  characteristic,  he  said.  He  then  argued  that  modem 
designers  must  strive  to  specify  subsystems  in  their  projects  so  that  they  were 
independent  in  this  sense,  lest  the  design  problems  they  face  become  so  complex  as 
to  be  insoluble.  (1) 

In  1973  Herbeit  Simon  made  a  similar  argument  with  respect  to  "decision- 
making" tasks  as  follows: 

"The  division  of  labor  is  quite  as  important  in  organizing  decision- 
making as  in  organizing  production,  but  what  is  being  divided  is  different  in 
the  two  cases.  From  the  information-processing  point  of  view,  division  of 
labor  means  factoring  the  total  system  of  decisions  that  need  to  be  made  into 
relatively  independent  subsystems,  each  one  of  which  can  be  designed  with 
only  minimal  concem  for  its  interactions  with  the  others.  The  division  is 
necessary  because  the  processors  that  are  available  to  organizations,  whether 
humans  or  computers,  are  very  limited  in  their  processing  capacity  in 
comparison  with  the  magnitude  of  the  decision  problems  that  organizations 
face.  The  number  of  altematives  that  can  be  considered,  the  intricacy  of  the 
chains  of  consequences  that  can  be  traced  ~  all  these  are  severely  restricted  by 
the  Umited  capacities  of  the  available  processors."  (2) 


The  information-processing  rationale  behind  this  criterion  for  problem-solving 
efficiency  was  noted  by  both  authors,  and  is  stated  compactly  by  Simon  in  the 
paragraph  quoted  above.  An  argument  for  the  criterion  can  also  be  made  on 
organizational  grounds  as  follows.  Problem-solving  that  extends  beyond  a  single 
individual  involves  communication  and  coordination  among  problem-solvers.  A 
task  boundary  between  problem-solvers  often  has  associated  with  it  physical  and 
organizational  barriers.  Such  barriers  can  add  to  the  cost  of  problem-solvers'  efforts 
to  achieve  cross-boundary  communication  and  coordination,  and  thus  reduce 
problem-solving  efficiency.  (Allen  has  shown  that  members  of  R&D  laboratories 
separated  by  either  physical  distance  or  or  organizational  barriers  (e.g.,  membership 
in  different  groups)  communicate  far  less  frequently  than  do  members  not  so 
separated. (3) ) 

The  reader  may  gain  a  better  intuitive  feeling  for  the  potential  strength  of  the 
link  between  innovation  project  efficiency  and  the  problem-solving  interdependence 
of  innovation  tasks  by  considering  two  very  simple  and  schematic  examples.  Each 
specifies  an  innovation  project  and  then  suggests  two  altemative  ways  to  divide  the 
project  into  two  component  tasks.  These  alternatives  differ  with  respect  to 
problem-solving  interdependence  between  tasks  and  -  as  a  consequence  I  suggest  - 
also  appear  to  differ  with  respect  to  the  efficiency  with  which  they  can  be  carried  out. 

First,  consider  how  one  might  partition  the  project  of  designing  an  airplane. 
In  fact,  of  course,  such  a  project  would  be  partitioned  into  thousands  of  tasks.  But, 
for  present  purposes  let  us  assume  that  it  will  be  partitioned  into  only  two  tasks,  each 
to  be  undertaken  by  a  different  firm.  The  two  altemative  partitionings  I  propose  we 
compare: 
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-  "Firm  X  is  responsible  for  the  design  of  the  aircraft  body  and  firm  Y  is 
responsible  for  the  design  of  the  engine, 

and: 

-  "Firm  X  is  responsible  for  designing  the  front  half  of  the  aircraft  body  and 
engine,  and  firm  Y  is  responsible  for  the  back  half  of  each. 

Taken  together,  each  of  these  proposed  partitionings  has  the  same  project 
outcome  -  a  complete  aircraft  design.  But  the  two  differ  greatly  with  respect  to  the 
interdependence  of  the  two  tasks  specified.  The  second  altemative  would  require  a 
much  higher  level  of  problem-solving  between  the  two  tasks.  For  example,  many 
design  decisions  affecting  the  shape  of  the  "front  half  of  an  aircraft  body  could  not 
be  made  without  forcing  related  changes  on  the  designers  of  the  back  of  the  body 
and  vice  versa:  The  two  halves  cannot  be  considered  independently  with  respect  to 
aerodynamics.  In  contrast,  the  detailed  design  of  a  complete  aircraft  engine  is  much 
less  dependent  on  the  detailed  design  of  a  complete  aircraft  body.  As  a  direct 
consequence,  I  suggest,  engineers  would  think  the  former  partitioning  far  more 
efficient  than  the  latter.  Indeed,  faced  with  the  latter  proposed  division,  experts 
would  be  likely  to  throw  up  their  hands  and  say,  "It  can't  be  done  that  way". 

As  a  second  example,  consider  how  one  might  partition  the  project  of 
designing  the  interiors  of  two  rooms  between  two  interior  decorators.  One  might 
assign  each  room  to  each  decorator;  one  might  assign  one-half  of  each  room  to  each. 
Again,  the  same  work  is  to  be  accomplished  in  each  instance.  Only  the  way  it  is 
divided  up  has  been  changed. 

In  this  example,  the  idea  of  two  interior  decorators  each  designing  one-half  of 
a  room  probably  seems  absurdly  inefficient  to  the  reader.  And  again,  I  propose  that 
this  is  because  of  the  need  for  between-task  problem-solving  that  is  inferred.  That 
is,  it  seems  reasonable  that  a  solution  devised  by  one  decorator  and  implemented  on 
one  side  of  a  room  must  cause  the  second  artist  to  make  responsive  adaptations  on 


the  other  side  of  the  room  if  a  satisfactory  total  design  is  to  result. 

We  can  see  that  it  is  the  need  for  problem-solving  across  tasks  that  makes 
these  partitionings  seem  inefficient  by  slightly  changing  the  nature  of  the  task  in  this 
second  example.  Suppose  that  problem-solving  is  clearly  not  involved  in  the 
room-design  project.  For  example,  suppose  that  the  physical  task  is  the  same  -  two 
interior  decorators  are  each  assigned  one-half  of  a  room  to  design  -  but  suppose  that 
the  decorators  work  for  a  hotel  chain  and  proceed  according  to  a  strict  formula,  hi 
that  case,  asking  each  decorator  to  design  half  a  room  might  be  a  perfecdy 
acceptable,  and  possibly  even  efficient,  partitioning  of  the  task.  For  example,  one 
decorator  could  specialize  in  applying  the  formula  to  window  decorations,  and  one 
could  specialize  in  applying  it  to  room  furnishings. 


4.0:  Understanding  and  Managing  Task  Partitioning 

If  improvements  to  innovation  task  partitioning  can  yield  major  benefits  to 
firms,  we  then  have  much  to  learn  about  it.  Firms  I  have  interviewed  to  date  appear 
not  to  think  about  task  problem-solving  interdependence  as  an  input  to  partitioning 
decisions  at  all,  at  least  not  explicitly,  histead,  some  appear  to  make  such  decisions 
primarily  on  the  basis  of  assumed  economies  of  specialization  (e.g.:  "All  electrical 
design  work  will  be  done  by  group  A";  "All  marketing  research  studies  will  be  done 
by  group  M").  Other  firms  appear  to  simply  follow  some  traditional  pattern  of 
innovation  task  partitioning  without  analysis.  (E.g.:  "We  have  always  designed 
aircraft  bodies  by  dividing  them  into  a  series  of  cylindrical  sections  and  assigning 
each  section  to  a  different  task  group.  No  one  now  at  the  company  has  thought 
about  why  we  do  this  or  whether  it  currently  makes  sense  from  any  point  of  view.  It 
is  just  the  way  we  do  it.") 

As  a  start  towards  research  on  the  matter,  let  me  consider  two  complementary 
approaches  to  managing  the  problem-solving  interdependence  of  innovation  project 
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tasks.  These  are:  (1)  relocating  task  partitions  so  as  to  reduce  the  need  for 
problem-solving  across  task  boundaries;  (2)  reducing  the  cost  of  engaging  in  a  given 
level  of  problem-solving  across  task  boundaries. 

Relocate  Task  Partitions 

In  order  to  locate  project  task  partitions  so  as  to  reduce  problem-solving 
interdependence  among  tasks  we  must  be  able  to,  first,  predict  which  tasks  are  likely 
to  be  the  source  of  important  new  information;  second,  predict  which  other  tasks  in 
the  network  are  likely  to  be  affected  by  that  new  information;  third,  use  such 
predictions  to  adjust  task  boundaries.  I  propose  that  these  things  can  be  done  to  a 
useful  degree  both  in  the  instance  of  "routine"  innovation  projects,  and  in  the 
instance  of  "very  novel"  ones.  Let  me  consider  each  of  these  project  types  in  tum. 

Most  innovation  projects  in  most  firms  do  not  involve  great  novelty.  Thus, 
computer  companies  specialize  in  repeatedly  developing  the  next  new  model 
computer,  and  auto  firms  specialize  in  repeatedly  developing  the  next  new  auto 
model.    Under  such  conditions,  innovators  learn  much  from  prior  projects  as  to 
areas  where  change  is  likely  to  be  needed  during  the  course  of  a  future,  similar 
innovation  project.  For  example,  an  engineer  experienced  in  auto  design  work  can 
look  at  specifications  for  a  new  model  car  and  easily  predict  the  areas  where  the  most 
difficult  design  problems  are  likely  to  be  encountered  during  the  course  of  the 
project. 

The  way  that  changes  to  a  given  task  are  likely  to  propagate  across  a  task 
network  can  also  often  be  predicted  by  project  personnel  who  have  experience  with 
similar  projects.  Thus,  changes  in  the  design  of  some  components  of  an  auto  engine 
can  be  expected,  with  a  near-certainty,  to  require  changes  in  other  design  tasks, 
because  the  tasks  are  predictably  interdependent  with  respect  to  problem-solving. 
For  example,  problem-solving  with  respect  to  the  shape  of  the  top  of  a  piston  in  an 
auto  engine  is  predictably  very  interdependent  with  the  task  of  problem-solving  with 
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respect  to  the  shape  of  a  cavity  in  the  cylinder  head  of  an  auto  engine:  The  two 
shapes  combine  to  form  the  overall  shape  of  an  auto  engine  combustion  chamber, 
and  the  shape  of  the  combustion  chamber  is  an  important  variable  in  engine  design. 
In  contrast,  the  likelihood  that  changes  to  either  or  both  of  these  components  will 
require  changes  in  the  tasks  of  designing  many  other  parts  of  the  auto  engine  - 
ranging  from  altemator  to  engine  mounts  -  will  be  seen  as  predictably  very  remote  by 
those  who  understand  auto  engine  design. 

In  sum,  in  the  instance  of  routine  innovation  projects,  it  is  reasonable  to 
expect  that  project  participants  can  predict  which  tasks  are  likely  to  be  the  source  of 
important  new  information,  and  which  other  tasks  in  the  network  are  likely  to  be 
affected  by  that  new  information.  Therefore  in  the  case  of  such  projects,  one  cam 
obtain  the  information  needed  to  readjust  task  boundaries  so  as  to  minimize  the  need 
for  cross -boundary  problem-solving.  Indeed  under  these  conditions,  one  may  be 
able  to  predict  the  course  of  problem-solving  so  well  as  to  be  able  to  lay  out  and 
partition  many  tasks  at  a  very  early  stage  in  an  innovation  project. 

In  the  instance  of  "very  novel"  projects,  an  abihty  to  predict  the  source  and 
pattern  of  problem-solving  at  the  outset  of  that  project  is  equivalent  to  saying  that  we 
be  able  to  predict  the  unexpected  -  not  a  very  promising  prospect.  However,  one  can 
still  improve  task  partitioning  with  respect  to  problem-solving  interdependence  under 
these  conditions  by  partitioning  as  the  project  unfolds. 

Consider  what  we  know  about  the  nature  of  the  engineering  problem-solving 
process.  Marples  (4)  has  found  that  engineering  problem  defmition  and  related 
problem-solving  evolve  in  a  hierarchical  manner  as  a  project  progresses.  Thus,  one 
may  start  a  project  only  knowing  that  one  wants  to  build  a  computer  that  is  "beyond 
the  state  of  the  art"  with  respect  to  speed  at  performing  certain  types  of  computation. 
But  many  designs  may  allow  one  to  reach  the  specified  goal,  so  the  designer's  first 
step  is  to  generate  and  analyze  alternative  approaches  in  a  preliminary  way.  (E.g.: 
"We  could  use  a  single  superfast  processor  or  use  multiple  processors  in  parallel".) 
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As  work  proceeds,  the  different  subproblems  (tasks)  that  are  associated  with  each 
approach  become  clearer,  (For  example,  engineers  may  identify  the  key 
subproblems  associated  with  the  parallel  processor  approach  as  innovative  computer 
architecture  and  software.  In  contrast,  the  key  subproblems  in  the  instance  of  a 
single  processor  approach  may  be  determined  to  be  the  design  and  fabrication  of  a 
processor  faster  than  any  made  before.)  The  team  elects  to  follow  the  approach(es)  it 
considers  most  promising  further,  and  elects  to  abandon  others  on  the  basis  of  early 
fmdings.  As  any  approach  is  followed  further  "sub-sub  problems"  specific  to  that 
particular  approach  emerge,  and  so  forth. 

Obviously  one  cannot  partition  a  task  before  one  knows  what  it  is.  But,  in  the 
scenario  just  described,  it  is  quite  possible  to  partition  emerging  tasks  as  the  project 
unfolds.  One  simply  thinks  through  what  one  can  predict  about  the  course  and 
pattem  of  problem-solving  as  work  progresses,  and  partitions  as  best  one  can  with 
an  eye  towards  minimizing  task  problem-solving  interdependence.  Such  an  effort  is 
not  very  risky,  because  full  accuracy  in  prediction  regarding  the  source  and  pattem 
of  problem-solving  activity  in  a  project  is  not  required  in  order  to  gain  from 
improved  task  partitioning.  This  is  because  all  project  tasks  are  not  likely  to  be 
interdependent,  and  the  effects  of  a  bad  partitioning  choice  made  in  one  area  of  a 
project  therefore  will  not  necessarily  propagate  to  affect  the  efficiency  gains  resulting 
from  good  choices  made  elsewhere. 

Currently,  I  am  not  aware  of  any  methods  that  can  enhance  practitioner  insight 
with  respect  to  identifying  likely  areas  and  patterns  of  change  in  an  innovation 
project.  Tools  do  exist,  however,  that  can  help  managers  to  record  and  to  think 
through  the  implications  of  their  insights.  Early  efforts  to  devise  and  experiment 
with  tools  for  this  purpose  (5,6,7)  were  not  picked  up  by  practitioners  insofar  as  I 
can  determine.  However,  a  graphical  method  called  "QFD"  has  recently  been 
developed  by  practitioners,  and  is  apparently  receiving  considerable  use. 

QFD  encourages  the  placing  of  customer  requirements,  engineering 
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requirements  and  manufacturing  requirements  with  respect  to  a  proposed  project 
onto  a  common  matrix,  so  that  interactions  and  possible  conflicts  can  be  identified 
and  discussed  by  project  team  members  at  an  early  stage  (8).  Thus,  the  method 
might  highlight  the  following  interaction:  "The  better  an  auto  door  is  at  tightly 
sealing  out  noise  and  dirt  (a  desirable  characteristic),  the  harder  it  is  to  close  (an 
undesirable  characteristic)  given  that  conventional  sealing  technology  is 
applied".  Such  information  can  be  used  as  an  aid  to  improving  task  partitioning. 
Thus,  if  project  specifications  require  improvements  in  door  closing  or  door  sealing, 
the  presence  of  the  interaction  with  respect  to  these  two  matters  suggests  that 
arranging  task  partitions  so  that  both  are  included  in  a  single  "improve  door  closing 
and  door  sealing"  task  would  reduce  task  problem-solving  interdependence  in  this 
instance. 

Ease   Cross-Boundary   Problem-Solving 

A  second  approach  to  managing  task  problem-solving  interdependence 
involves  reducing  the  cost  of  engaging  in  problem-solving  across  task  boundaries. 
This  approach  is  complementary  to  the  one  discussed  above:  It  regards  existing  task 
partitions  as  given,  and  seeks  ways  to  minimize  the  costs  of  any  associated 
cross -boundary  problem-solving.  Therefore,  both  approaches  can  be  applied 
simultaneously  when  attempting  to  manage  the  effects  of  task  problem-solving 
interdependence. 

There  has  long  been  a  literature  in  the  field  of  organizational  behavior  that 
explores  ways  to  pass  information  across  group  boundaries,  or  to  integrate  groups 
divided  by  a  boundary.  Therefore  some  tools  for  lowering  the  cost  of 
problem-solving  across  boundaries  are  reasonably  well  understood.    Naturally 
occurring  mechanisms  to  this  end  such  as  the  "gatekeeper"  who  takes  on  the  role  of 
passing  information  between  organizations  have  been  described.(9)  Also,  various 
inventions  developed  specifically  to  accomplish  boundary  spanning  such  as  the  "inte- 
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grating  group"  (10)  have  been  described  by  specialists  and  been  applied  in  the  field. 

One  could  address  such  tools  to  our  present  problem  by  first  predicting  where 
high  interaction  between  tasks  will  be  required,  and/or  monitoring  task  activities  to 
identify  such  needs  as  they  arise.  Then,  special  efforts  could  be  made  to  ease 
communication  across  the  relevant  task  boundaries.  Thus,  in  this  second  approach 
one  might  keep  the  door-closing  and  door-sealing  activities  described  earlier  as  two 
independent  tasks.  But,  upon  noting  the  problem-solving  interdependence  between 
them,  one  could  take  steps  to  facilitate  problem-solving  interaction  across  that 
particular  boundary. 

There  is  also  a  more  recent  literature  reporting  on  the  experience  of  some 
Japanese  firms  in  this  matter.  Here,  the  emphasis  appears  to  be  less  on  specific 
mechanisms  intended  to  span  a  particular  boundary  for  a  particular  end,  and  more  on 
organizational  designs  that  encourage  a  general  high  level  of  communication  and  a 
reduction  of  barriers  to  communication  and  joint  problem-solving  between  all  project 
tasks. 

Thus,  Imai,  Nonaka  and  Takeuchi  report  that  five  very  successful  product 
development  projects  by  Japanese  firms  used  multifunctional  development  teams  of 
30  or  fewer  people  to  develop  relatively  complex  products  having  a  significant 
degree  of  novelty  in  their  fields.  (Honda,  the  'City'  car;  Fuji-Xerox,  the  FX-3500 
copier;  Canon,  the  'Sure  Shot'  camera;  NEC,  the  PC  8000  personal  computer; 
Epson,  the  MP-80  dot  matrix  computer  printer).  They  point  out  many  ways  in 
which  these  teams  were  designed  to  maximize  within-team  information  flow  and 
minimize  task  boundaries,  and  contrast  this  with  US  product  development  practice. 
Thus,  they  note  that  project  phases  such  as  product  concept,  feasibility,  defmition 
and  design  -  often  sharply  demarked  in  US  practice  with  progress  reviews  and 
approvals  -  were  much  less  defmed  and  overlapped  more  heavily  in  the  practice  of 
the  Japanese  teams: 
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"The  loose  coupling  of  [project]  phases  also  makes  the  division  of 
labor,  in  the  strict  sense  of  the  word,  ineffective.  Division  of  labor  works 
well  in  a  [US  style]  system  where  the  tasks  to  be  accomplished  in  each  phase 
are  clearly  delineated  and  defined.  Each  project  member  knows  his  or  her 
responsibility,  seeks  depth  of  knowledge  in  a  speciaUzed  area,  and  is 
evaluated  on  an  individual  basis.  But  such  segmentahsm  ...  works  against  the 
grain  of  a  loosely  coupled  system  [such  as  that  observed  in  the  Japanese 
development  projects].  Here,  the  norm  is  to  reach  out  across  functional 
boundaries  as  well  as  across  different  phases.  Project  members  are  expected 
to  interact  with  each  other  extensively,  to  share  everything  from  risk,  responsi- 
bility [and]  information  to  decision-making,  and  to  acquire  breadth  of 
knowledge  and  skills. "(11) 

Under  such  conditions,  barriers  between  many  project  tasks  may  indeed  be  very  low 
and  flexible,  thus  reducing  the  need  to  make  special  accommodation  for  those  tasks 
having  high  interdependence  with  respect  to  problem-solving. 


5.0:  Practical  Importance 

Is  management  of  the  problem-solving  interdependence  of  tasks  a  matter  of 
any  practical  importance  to  innovators?  I  think  so,  and  will  illustrate  the  possibility 
anecdotally  by  looking  at  two  areas  in  the  innovation  process  that  are  known  to  be 
problematic  through  the  lens  of  task  partitioning.  The  first  of  these  is  commonly 
called  the  "marketing-R&D"  or  "marketing  research  -  product  design"  interface  in  the 
innovation  process  literature.  The  second  is  typically  referred  to  as  the  "product 
design  -  process  design"  or  "design-build"  interface  in  that  literature.  These  two 
interfaces  are  the  boundaries  between  the  three  tasks  of  marketing  research,  product 
design  and  process  design.  All  three  tasks  are  typically  carried  out  (in  series  or  with 
some  time  overlap)  during  the  course  of  an  innovation  project.  In  what  follows,  I 
will  first  consider  the  "design-build"  interface  in  some  detail.  Then  I  will  more 
briefly  incorporate  the  marketing-R&D  interface  into  the  discussion. 


16 

The  Product  Design  -  Process  Design  Interface 

Traditionally,  the  interface  between  product  design  and  process  design  has 
been  a  source  of  difficulty  in  the  progress  of  an  innovation  project.  Traditionally, 
also,  this  difficulty  has  been  framed  as  the  problem  of  transferring  information 
smoothly  and  completely  from  the  former  to  the  latter.(12)  More  recently,  however, 
the  underlying  assumption  of  a  one-way  flow  from  product  design  to  process  design 
has  begun  to  be  seen  as  a  problem  in  itself.  In  essence,  researchers  and  practitioners 
now  better  appreciate  that  the  product  and  process  design  tasks  can  interact  in  a  way 
that  requires  two-way  communication  and  joint  problem-solving  between  the  groups 
engaged  in  these.  That  is,  the  way  you  design  a  product  has  implications  for  process 
design  -  and  vice  versa. 

For  example,  a  product  designer  may  initially  design  a  component  part  that  is 
very  difficult  to  manufacture  -  despite  instructions  and  good  intentions  -  because  he 
does  not  understand  manufacturing  processes  well.  He  will  typically  be  able  to 
change  his  design  to  resolve  the  problem  -  if  told  of  the  difficulty  in  a  timely  manner. 
But  if  product  designers  only  provide  information  to  process  designers  at  the 
completion  of  product  design,  there  will  obviously  be  no  opportunity  for  process 
designers  to  provide  the  needed  data  during  the  time  when  the  design  work  is  still 
under  way  and  changes  could  be  relatively  easily  accommodated. 

Two  empirical  studies  I  am  aware  of  have  examined  the  design-build 

interface,  and  have  shown  that  an  increase  in  interaction  across  this  boundary  is 

associated  with  increased  project  efficiency.  Thus,  authors  of  a  study  of  the  matter 

in  the  commercial,  power,  light  industrial  and  heavy  industrial  segments  of  the 

constmction  industry  found  that: 

"a  construction  specialist  [building  constructor],  working  with  the  engineering 
team  [building  designers]  as  the  project  is  defined  and  designed,  can  cut  costs 
by  10  to  20  times  the  added  cost  of  extra  personnel.  On  a  $30  million  project, 
an  extensive  constructability  program  may  cost  $50,000,  but  can  bring 
savings  of  $1  million.  Costs  and  schedules  are  trimmed  by: 
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-  Arranging  the  optimum  preparation  of  both  engineering  details  and  the 
sequence  in  which  they  are  prepared  so  as  to  avoid  delays  in  construction  on 
the  site. 

-  Taking  advantage  of  the  latest  construction  technology  as  part  of  the  design. 

-  Developing  work-simphfying  methods  and  minimizing  labor-intensive 
design."(13) 

Similarly,  Clark  et  al.  (14),  in  a  recent  comparison  of  aspects  of  the  European, 
Japanese  and  US  auto  industries,  provide  a  detailed  case  study  of  how  information 
was  passed  between  designers  of  the  sheet-metal  parts  that  make  up  the  surface  of  an 
automobile,  and  the  designers  of  the  dies  used  to  produce  these  parts.  In  the 
Japanese  firms,  they  found,  the  work  of  parts  designers  and  dies  designers  had  a 
larger  overlap  with  respect  to  time  than  did  US  and  European  firms.  They  also 
found  that  Japanese  parts  designers  typically  passed  preliminary  information  more 
frequently  to  die  designers  regarding  the  planned  shape  of  parts  as  work  progressed.(15) 
As  a  consequence,  they  suggest,  die  designers  in  the  Japanese  firms  were  in  a  better 
position  to  begin  the  design  of  dies  while  some  areas  of  shape  were  still  uncertain, 
and  to  suggest  changes  to  part  designers  in  a  timely  fashion  that  would  reduce  the 
cost,  complexity  or  number  of  dies  required  to  make  the  part. 

On  the  basis  of  studies  such  as  these,  plus  anecdotal  reports  of  good  results  in 
various  firms  with  "design-build"  teams,  practitioners  and  researchers  are  now 
moving  to  the  view  that  closer  interaction  between  product  and  process  design  is  in 
general  beneficial.  However,  if  we  view  this  problem  through  the  lens  developed  in 
this  paper  -  that  one  wants  to  partition  tasks  so  as  to  minimize  the  need  for 
problem-solving  across  task  boundaries  and/or  build  bridges  between  tasks 
anticipated  to  require  high  problem-solving  interaction  -  then  we  can  advance  the 
discussion  a  step  further,  in  my  view. 
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I  propose  that  the  level  of  benefit  obtained  from  bridging  or  eliminating  the 
task  boundary  between  product  design  and  process  design  will  differ  as  a  function  of 
the  particular  part  and  process  at  issue.  This  is  because,  as  discussed  earlier,  the 
need  for  problem-solving  across  such  a  boundary  can  vary  depending  on  the 
particular  part  and  process  involved,  and  depending  upon  the  specifications  set  for 
task  outcomes. 

Thus,  in  the  case  study  by  Clark  et  al.  mentioned  above,  the  design  of  auto 
parts  and  of  the  dies  used  to  produce  them  are  clearly  very  interdependent  design 
tasks,  and  it  therefore  seems  reasonable  that  the  bridging  or  elimination  of  the 
boundary  between  these  two  tasks  would  improve  innovation  process  efficiency  and 
effectiveness. 

On  the  other  hand,  I  would  suspect  that  one  would  not  typically  get  a  similar 
benefit  by  bridging  or  eliminating  the  task  barrier  between  product  design  and 
process  design  in  the  instance  of  "middle-of-the-road"  printed  circuits.  This  is 
because  standard  printed  circuit  manufacturing  technology  is  capable  of  producing 
any  such  ordinary  circuit  without  any  process  adjustments  being  needed  or  useful. 
That  is,  there  will  not  usually  be  a  need  for  joint  problem-solving  -  or  two-way 
communication  -  between  these  two  tasks.  (Those  unfamiliar  with  printed  circuit 
technology  can  think  of  book  printing  as  a  useful  substitute  example.  Book  authors 
typically  do  not  have  to  write  their  books  with  the  needs  of  the  printer  in  mind, 
because  the  ordinary  printing  process  does  not  have  to  be  adapted  to  the  particular 
words  chosen  by  an  author.  In  contrast,  a  graphics  designer  trying  to  do  something 
that  pushes  the  limits  of  existing  printing  processes  might  well  fmd  joint 
problem-solving  with  the  printer  to  be  very  valuable.) 

The  need  to  make  choices  with  respect  to  where  one  will  eliminate  task 
boundaries  and/or  increase  interaction  across  them  can  be  illustrated  by  reference  to 
the  practice  of  some  auto  manufacturers  and  others  of  sometimes  specifying 
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components  they  want  simply  as  "black  boxes".  In  such  cases  the  work  of 
designing  the  components  in  detail  is  assigned  to  the  supplier  firms  that  will 
manufacture  them.(16) 


Figure  2A 


Auto  Firm: 


Component  B 
Manufacturer: 


Design  Component  A  ^    Design  Component  B 
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Figure  2:  Shifting  the  detailed  design  of  one  product  component  (Component  B) 
from  the  firm  designing  the  product  to  the  firm  that  will  manufacture  it  improves  the 
design-build  linkage  for  Component  B  -  but  weakens  the  design  Unkage  between 
Component  A  and  Component  B. 


As  is  suggested  in  Figure  2,  a  shift  of  the  detailed  design  of  automobile 
component  B  from  the  firm  that  designs  the  overall  automobile  to  the  firm  that  builds 
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the  component  probably  increases  the  barriers  between  the  design  of  component  A 
and  component  B,  while  decreasing  the  barrier  between  product  design  and  process 
design  for  these  components.  After  all,  the  shift  involves  a  shift  in  the  physical  and 
organizational  location  of  the  component  design  work  from  a  close(r)  proximity  with 
other  design  tasks,  and  to  a  closer  proximity  with  process  design  tasks.  And,  as 
mentioned  earlier,  Allen  (3)  has  shown  that  both  physical  and  organizational  distance 
presents  significant  barriers  to  technical  communication. 

Clark  et  al.  have  found  the  assignment  of  greater  amounts  of  detailed 
component  design  work  to  component  suppUers  to  be  strongly  associated  with  a 
reduction  in  the  time  required  to  develop  a  new  model  car.  Indeed,  they  estimate  that 
"bringing  an  additional  twenty  percent  of  the  engineering  effort  in-house  and  inside 
the  project  [that  is,  assigning  less  of  the  detailed  component  design  work  to  the 
component  supplier]  would  add  eight  months  to  project  lead  time. "(17). 

In  line  with  arguments  made  earlier,  I  suggest  that  further  examination  will 
show  that  the  effect  of  this  shift  is  positive  only  for  those  components  where  there  is 
less  benefit  obtainable  from  problem-solving  interaction  between  particular 
component  design  tasks  than  between  the  tasks  of  product  design  and  process 
design.  For  example,  I  suspect  that  shifting  the  detailed  design  of  an  electrical 
altemator  (generator)  to  be  used  in  a  new  model  car  from  the  auto  design  firm  to  the 
component  manufacturer  would  result  in  a  net  improvement  in  efficiency:  there  is 
little  design  trade-off  between  generator  design  and  the  design  of  other  components. 

On  the  other  hand,  if  the  component  in  question  is  the  plastic  ducting  used  to 
distribute  hot  and  cold  air  to  a  car's  interior,  I  would  expect  the  reverse  to  be  true. 
Such  ducting  is  bulky,  and  must  be  laid  out  with  an  intimate  knowledge  of  the 
location  and  size  of  many  other  auto  components  if  it  is  to  be  fitted  within  the  car 
properly.  To  carry  out  this  design  process  efficiently,  it  seems  to  me,  there  would 
be  a  need  for  creative,  interactive  problem-solving  involving  the  designers  of  the  car 
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as  a  whole  and  the  designers  of  the  air  ducting  components.  Thus,  the  gain  from 
reducing  the  barriers  to  such  interaction  by  keeping  both  design  tasks  within  the  auto 
manufacturer  seems  to  me  likely  to  outweigh  any  advantage  to  be  gained  from 
shifting  detailed  design  to  the  manufacturer  in  this  instance. 

The  Marketing  Research  -  Product  Design  Interface 

The  interface  or  boundary  between  the  marketing-R&D  interface  has  long 
been  judged  to  be  a  source  of  problems  with  respect  to  the  commercial  success  of 
innovation  projects  because  most  new  products  developed  fail  in  the  marketplace 
(18);  accurate  understanding  of  user  need  has  been  shown  key  to  innovation  project 
success  (19);  engineers  and  marketers  are  often  unhappy  with  the  quality  of  the 
information  regarding  user  need  transmitted  across  the  mariceting-R&D  interface 
(20). 

As  was  the  case  with  the  design-build  interface,  the  "interface  problem"  has 
been  traditionally  seen  as  one  of  smooth  and  accurate  transfer  of  "need"  information 
from  marketing  to  product  designers.  Today,  however,  improved  two-way 
communication  across  this  interface  is  now  clearly  identified  as  a  likely  way  to 
improve  performance  at  this  interface. (21)  However,  as  in  the  case  of  the 
design-build  interface,  I  suggest  that  the  benefit  realizable  from  repartitioning  tasks 
to  eliminate  the  boundary  between  marketing  research  and  product  design,  or  taking 
steps  to  ease  problem-solving  across  that  boundary,  will  depend  on  the  amount  of 
joint  problem-solving  required  across  the  interface  in  any  particular  instance. 

Thus,  a  single  one-way  message  from  marketing  to  product  design  may 
suffice  if  the  need  information  is  unambiguous,  and  if  the  designers  can 
accommodate  the  request  without  compromising  other  product  characteristics. 
E.g.,  "The  customer  wants  this  software  to  interface  with  the  XYZ  printer."  On  the 
other  hand,  joint  problem-solving  between  marketing  researchers,  customers,  and 
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product  designers  will  clearly  be  valuable  when,  for  example,  data  on  new  product 
needs  provided  by  marketing  research  to  engineering  have  consequences  or  offer 
opportunities  that  are  not  initially  visible  to  all  these  parties.  E.g.,  "Are  you  aware 
that  adding  memory  to  the  computer  as  you  request  will  make  it  slower?"  Or,  "Do 
you  realize  that  if  we  add  extra  memory  we  can  also  add  feature  X  at  no  cost?" 


6.0:  Discussion  and  Suggestions  for  Further  Research 

In  this  paper  I  have  proposed  that  the  level  of  problem-solving 
interdependence  between  tasks  is  a  function  of  choices  made  with  respect  to  task 
partitioning.  I  have  also  suggested  that  such  choices  can  be  managed,  and  that  doing 
so  may  have  an  important  impact  on  innovation  process  efficiency.    It  seems  to  me 
that  these  proposals  are  worth  exploring  further  from  the  point  of  view  of  both 
innovation  process  research  and  innovation  practice. 

Innovation  task  partitioning  is  potentially  a  very  interesting  topic  in  the  field  of 
innovation  process  research  because  it  bears  directly  on  the  matter  of  how  innovation 
can  be  most  efficiendy  distributed  within  and  among  firms.  Findings  related  to 
partitioning  can  therefore  serve  as  a  useful  input  to  research  on  topics  ranging  from 
specialization  to  vertical  integration  to  the  role  of  suppliers  in  the  innovation  process. 

In  such  research,  the  conditional  nature  of  improvements  to  innovation 
process  efficiency  as  a  result  of  changes  in  task  partitioning  will  become  evident  and 
important.  That  is,  decisions  regarding  partitioning  influence  far  more  than  problem- 
solving  efficiency.  They  also  have  an  impact  on  matters  ranging  from  the  efficient 
utilization  of  speciaUzed  resources,  to  the  abihty  of  a  firm  to  protect  its  innovation- 
related  advantages  in  the  maricetplace.  Sometimes  partitioning  from  the  point  of 
view  of  minimizing  problem-solving  interdependence  among  tasks  will  have  positive 
impacts  on  these  related  matters,  but  sometimes  a  trade-off  of  benefits  wiU  be 
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required.  (E.g.,  "We  would  gain  efficiency  if  the  manufacturer  of  component  X 
worked  with  our  designers  at  an  early  stage,  but  this  strategy  would  also  increase 
our  risk  that  news  of  our  new  product  might  leak  out  early  and  reduce  our  profits.") 

Since  there  is  more  than  one  solution  possible  to  most  design  problems,  the 
way  a  project  is  partitioned  into  tasks  will  also  strongly  influence  the  nature  of  the 
solution  ultimately  developed  by  a  project  team.  Thus,  an  auto  firm  project  team  that 
chooses  to  design  an  auto  engine  and  auto  transmission  as  one  task  will  probably 
come  up  with  a  different  design  -  and  will  surely  leam  more  about  engine- 
transmission  interactions  -  than  a  team  that  partitions  engine  design  and  transmission 
design  into  separate  tasks. 

An  improved  understanding  of  innovation  task  partitioning  will  be  important 
to  innovation  managers  if  and  as  it  can  have  an  important  impact  on  innovation 
project  efficiency  and  effectiveness.  The  magnitude  of  this  effect  needs  to  be 
empirically  explored.  As  an  initial  step,  it  might  be  reasonable  to  attempt  to  view  the 
efficiency  effects  of  innovation  project  task  partitioning  in  isolation.  One  might  be 
able  to  do  this  experimentally  by,  for  example,  systematically  varying  the  way  a 
given  development  project  is  divided  into  modules  (tasks)  and  observing  the  effect  of 
these  variations  on  project  performance  and  outcomes. 

Next,  it  might  be  reasonable  to  explore  the  possibility  of  managing  innovation 
task  partitioning  in  practice  to  achieve  efficiency  and  effectiveness  gains  in 
innovation  project  work.    For  example,  one  might  select  a  sample  of  innovation 
projects  for  study,  list  the  major  tasks  associated  with  each,  and  then  ask  project 
participants  to:  (1)  rank  the  degree  of  problem-solving  interaction  required  among 
different  listed  tasks,  and  (2)  rank  the  ease  of  accomplishing  such  problem-solving 
among  these  same  tasks.  A  large  mismatch  between  the  answers  to  the  two 
questions  might  indicate  that  practically  useful  task  partitioning  changes  could  be 
made,  and  would  also  suggest  where  these  might  lie. 
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If  work  such  as  that  described  above  does  show  that  improvements  in  task 
partitioning  with  respect  to  problem-solving  can  offer  major  benefits  to  firms,  we 
must  learn  more  about  how  to  manage  it.  In  this  regard,  it  is  important  to  point  out 
that  "management"  does  not  necessarily  imply  management  from  the  top  or  by 
specialists:  Indeed,  it  is  very  possible  that  decisions  regarding  task  partitioning  and . 
needed  communication  across  task  boundaries  can  be  most  effectively  managed  at 
the  working  level.    After  all,  that  is  where  problem-solving  is  done  and  where  the 
fast-changing  data  on  the  nature  of  needed  problem-solving  originate.  (Interestingly, 
firms  that  try  to  manage  task  partitionings  at  a  higher  level  may  find  project 
participants  making  informal  and  perhaps  covert  adjustments  in  any  case  (22).) 

I  look  forward  to  studying  innovation  task  partitioning  further,  and  very  much 
hope  that  others  wiU  also  find  the  area  interesting  enough  to  explore. 
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